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THe projecT, a comPLex HeaLTHcare FacniTY, was in TrouBLe. rae 
money anD Time were Gone, but mere was PLenry of disttust anD 
mis-coormnaTion. 


Scheduling work seemed impossible; the design was 

filled with conflicts, and it kept changing. Supervisors 
were torn between finding work ready for today and 
trying to solve problems for tomorrow. It wasn't much 
fun, and the client was very unhappy. There was so 
much to do — and so little time — that it was hard to 
know where to start. 

Design issues dominated the weekly planning 
meeting, so I went there to listen and learn. After new 
issues were identified and discussed, the 
meeting turned to review the status of 
unanswered RFIs. These Requests For 
Information typically originate in the 
contractor organization and are used to 
define, manage, and track solutions. 

Going down the list, Carl, 
the contractor’s project manager, 
spoke to Dan the architect. "Dan, we need to 
resolve RFI 173." Dan shook his head in agreement, 
and they moved on to RFI 204. I wasn't at all 
sure what had happened or how to interpret this 
brief interchange. 

After the meeting, I caught up with Carl and asked 
if Dan had promised to solve the problem. Carl was 
convinced that he had. I was not so sure, so we caught 
up with Dan and I asked, "Did you promise Carl to 
answer 173?" Dan was surprised and confused. "How 
could I?" he said. "I agree we need to get it resolved, but 
Carl owes me some vendor data before we can decide.” 


Carl was taken aback; he had forgotten his promise 
to Dan. But after a quick discussion, both were back 
on track. 

Walking away, I asked Carl why he had framed his 
request, "Dan, we need to resolve RFI 173.” He said 
this was a nicer, more team-friendly way of talking. 
He claimed, "It puts us in the problem together." Carl 
and I are pretty good friends, so I took him straight on. 
"Teamwork isn't about being soft and unclear," I told 
him. "It requires making clear requests 
and securing reliable promises. Don’t 
be a wimp — ask for what you want. 
And don’t be a flake — do what you say 
you are going to do.” 

Coordinating work in projects and 
keeping projects under control is a 
matter of people making and keeping 
the commitments that release work to others in the 
right sequence. A project can be understood as a 
network of commitments that links the work of the 
specialists to the promise of the project and coordinates 
their action. Carl makes a request to Dan... Dan asks for 
vendor data. . . Carl asks his assistant. . . somewhere a request is 
mistaken for an opinion, or the nod of the head is interpreted as 
a promise. Planning systems can provide the structure 
and circumstance for planning conversations, but 
systems don’t make work happen. People make work 
happen by making requests and keeping promises to 
one another. 


commumenTS are 
Beiween peoPLe, 
I10T SCHCDULeS. 
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doitt se awmp-asKForwnaT you warn. 


There are ways to tell when you are making a 
reliable promise. Ask yourself if you can say one or 
more of the following: 

1. I am competent enough to perform, or 1 have 
access to competence. 

2. I estimated the amount of time (hands-on) 
required for this work. 

3. 1 have the capacity available to do the work and 
have allocated it to the task. 

4. I am not having a private unspoken conversation 
in conflict with my promise. 

5. I will be responsible; I'll clean up the mess if I 
can’t deliver. 

Commitments are between people, not schedules. 
Project management as practiced today creates a 
"commitment-free zone," because it assumes that people 
will commit to centrally managed schedules without 
providing a mechanism to ensure their work can be 
done. So they give it their best, but something always 
seems to come up... "I tried, but you know how it is." 

This form of project management does not provide 
a mechanism to ensure that what should be done, can in 
fact be done at the required moment. Too often , promises 


made in coordination meetings are conditional and 
unreliable. It has been my experience that at times 
trust can be low and hard to build in this environ- 
ment. The absence of reliable promises explains why 
on well-run projects, people are often only completing 
30-50 percent of the deliverables they’d promised for 
the week. 

We all know what a promise is; we have plenty of 
experience making them and receiving them from others. 
So what's the problem? The sad fact is that the project 
environment — like many other work environments — 
is often so filled with systemic dishonesty, that we don’t 
expect promises that are reliable. Project managers 
excel when they manage their projects as networks of 
commitments and help their people learn to elicit and 
make reliable promises. • 
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